--- /dev/null
+<appendix id="Styles">
+<title>GPSBabel XCSV Style Files</title>
+<para>
+The format of an XCSV style file is quite simple and designed to be easily
+implemented by non-programmers to handle "one-off" babel-ization of various
+XCSV (whatever separated values) text files. The format and usage of the
+various style directives are described below.
+</para>
+<para>
+The first and foremost important step is understanding how the config
+file is laid out itself. The format is:
+</para>
+<screen format="linespecific">DIRECTIVE<whitespace>VALUE</screen>
+<para>
+Where <whitespace> is a space, tab, spaces, tabs, etc... There should
+be nothing before the directive. (i.e. not " DIRECTIVE VALUE")
+</para>
+<section id="styles_internal_const">
+<title>Internal Constants</title>
+<para>
+A few internal constants are defined in the XCSV parser to make the style
+file simpler. They may or may not be used and are optional in most cases.
+Note that only certain style file directives map these constants.
+</para>
+<screen format="linespecific">
+STYLE CONSTANT MAPS TO CHAR(s)
+---------------------------------------
+COMMA ,
+COMMASPACE ,<space>
+SINGLEQUOTE '
+DOUBLEQUOTE "
+COLON :
+SEMICOLON ;
+NEWLINE \n
+CR \r
+CRNEWLINE \r\n
+TAB \t
+SPACE <space>
+HASH #
+PIPE |
+WHITESPACE *** SEE WHITESPACE NOTES BELOW ***
+</screen>
+<section id="style_const_whitespace">
+<title>WHITESPACE</title>
+<para>
+The WHITESPACE constant has special properties. When reading data,
+WHITESPACE refers to sequential runs of SPACES and/or TABS. When
+writing data, WHITESPACE is always a single SPACE.
+</para>
+<para>
+For example, the following line:
+</para>
+<screen format="linespecific">
+SOME_NAME 30.1208 -91.1365 SOME OTHER NAME
+</screen>
+<para>
+Parses into the following data fields:
+</para>
+<screen format="linespecific">
+SOME_NAME,30.1208,-91.1365,SOME,OTHER,NAME
+</screen>
+</section>
+
+<section id="style_const_comments">
+<title>COMMENTS</title>
+<para>
+Anything after a hash (#) on a line is not parsed. For example:
+</para>
+<screen format="linespecific">
+#THIS ENTIRE LINE IS A COMMENT.
+#FIELD LAT_DECIMAL, "", "%f" THIS ENTIRE LINE IS A COMMENT
+FIELD LAT_DECIMAL, "", "%f" # ONLY THIS SENTENCE IS A COMMENT.
+</screen>
+</section>
+</section> <!-- internal constants -->
+
+<section id="style_global">
+<title>Global Properties of the File</title>
+<para>
+There are a few available directives to describe general traits of the
+file being described and not specific data within the file itself.
+</para>
+<section id="style_global_description">
+<title>DESCRIPTION</title>
+<para>
+This is the description of the file format being described. This text
+appears in the help screens and in menus used by the various GUI wrappers.
+</para>
+</section>
+<section id="style_global_extension">
+<title>EXTENSION</title>
+<para>
+This directive gives the filename extension generally associated with
+this file.
+</para>
+</section>
+<section id="style_global_encoding">
+<title>ENCODING</title>
+<para>
+Describes the character set used by this format. The value given
+must be one listed by 'gpsbabel -l'. example:
+</para>
+<screen format="linespecific">
+ ENCODING UTF-8 # Use UTF-8 for input and output.
+</screen>
+</section>
+</section> <!-- global -->
+
+<section id="style_behavior">
+<title>GPSBabel Behavior Directives</title>
+<para>
+There are a few available directives to control some of the internal
+processing functions of GPSbabel.
+</para>
+<section id="style_behave_shortlen">
+<title>SHORTLEN</title>
+<para>
+ This sets the maximum allowed shortname length when using the internal
+ shortname synthesizer.
+</para>
+<para>
+ example:
+</para>
+<screen format="linespecific">
+ SHORTLEN 16 # shortnames will be at most 16 characters long.
+</screen>
+</section>
+
+<section id="style_behave_shortwhite">
+<title>SHORTWHITE</title>
+<para>
+ This tells the shortname synthesizer whether or not to allow whitespace
+ in the synthesized shortnames. Allowed values are zero and one.
+</para>
+<para>
+ example:
+</para>
+<screen format="linespecific">
+ SHORTWHITE 0 # Do not allow whitespace in shortname.
+ SHORTWHITE 1 # Allow whitespace in shortname.
+</screen>
+</section>
+</section> <!-- behavior -->
+
+<section id="style_layout">
+<title>Defining the Layout of the File</title>
+<para>
+The first few directives define the layout the physical file itself:
+</para>
+
+<section id="style_layout_field">
+<title>FIELD_DELIMITER</title>
+<para>
+ The field delimiter defines the character(s) that separate the fields in
+ the rows of data inside the XCSV file. Common field delimiters are commas
+ and tabs. (referred to as "comma separated values" and "tab separated
+ values")
+</para>
+<para>
+ examples:
+</para>
+<screen format="linespecific">
+ FIELD_DELIMITER COMMA
+ FIELD_DELIMITER ~
+</screen>
+<para>
+ The directive FIELD_DELIMITER is parsed for STYLE CONSTANTS as defined in
+ the table above.
+</para>
+</section>
+
+<section id="style_layout_rec">
+<title>RECORD_DELIMITER</title>
+<para>
+ The record delimiter defines that character(s) that separate ROWS of
+ data (FIELDS) in the XCSV file. The most common record delimiters
+ are NEWLINE and CR (carriage return).
+</para>
+<para>
+ examples:
+</para>
+<screen format="linespecific">
+ RECORD_DELIMITER NEWLINE
+ RECORD_DELIMITER |
+</screen>
+<para>
+ The directive RECORD_DELIMITER is parsed for STYLE CONSTANTS as defined
+ in the table above.
+</para>
+</section>
+
+<section id="style_layout_badchars">
+<title>BADCHARS</title>
+<para>
+ Bad characters are things that should *never* be written into the XCSV
+ file as data on output. GPSBabel automatically includes any non-blank
+ FIELD_DELIMITER and RECORD_DELIMITER characters as BADCHARS by default.
+</para>
+<para>
+ examples:
+</para>
+<screen format="linespecific">
+ BADCHARS COMMA
+ BADCHARS ~|
+</screen>
+<para>
+ The directive BADCHARS is parsed for STYLE CONSTANTS as defined in the
+ table above.
+</para>
+</section>
+
+<section id="style_layout_prologue">
+<title>PROLOGUE</title>
+<para>
+ A prologue is basically constant data that is written to the output
+ file BEFORE any waypoints are processed. PROLOGUE can be defined
+ multiple times in the style file, once for each "line" before the data
+ begins. This is commonly used in XCSV files as a "header" row.
+</para>
+<para>
+ examples:
+</para>
+<screen format="linespecific">
+ PROLOGUE OziExplorer Waypoint File Version 1.1
+ PROLOGUE WGS 84
+ PROLOGUE Symbol,Name,Latitude,Longitude
+</screen>
+</section>
+
+<section id="style_layout_epilogue">
+<title>EPILOGUE</title>
+<para>
+ An Epilogue is the same as a prologue, except this data is written at
+ the END of the file. See the examples for PROLOGUE above.
+</para>
+</section>
+</section> <!-- layout -->
+
+<section id="style_define">
+<title>Defining Fields Within the File</title>
+<para>
+A field defines data. There are two different classifications of FIELDS,
+IFIELD (file input) and OFIELD (file output). In the absence of any OFIELDS,
+IFIELDS are use as both input and output. The existence of OFIELDS is
+primarily to allow more flexible mapping of GPSBabel data to output data
+(say, for instance, to map the internal GPSBabel "description" variable to
+two or more fields on output). For all practical purposes, IFIELDS and
+OFIELDS are defined the same way in the style file. The following options
+are defined:
+</para>
+<itemizedlist>
+<listitem>
+<para>
+ "no_delim_before" is supported on OFIELD tags to specify that this
+ field should be written without a field delimiter before it. It's
+ useful for limited field concatenation.
+</para>
+</listitem>
+
+<listitem>
+<para>
+ "absolute" is supported on OFIELD tags for lat and lon to indicate
+ that only absolute values (never negative) are to be printed.
+</para>
+</listitem>
+</itemizedlist>
+
+<para>
+There are several different types of fields that may be defined. Each field
+consists of three pieces of information: the FIELD TYPE, a DEFAULT VALUE, and
+a PRINTF CONVERSION (for output). In many cases, not all pieces are used,
+but all 3 pieces are required. Additionally, an fourth field is supported
+that modifies the behaviour of the field being described.
+</para>
+<para>
+FIELDS should be defined in the style file in the logical order that they
+appear in the data, from left to right. This is the order in which they are
+parsed from input and written to output.
+</para>
+<para>
+The fields used by the XCSV parser are as follows:
+</para>
+
+<section id="style_def_ignore">
+<title>IGNORE</title>
+<para>
+ IGNORE fields are, guess what, ignored on input. Internally, IGNORE
+ fields are treated as CHARACTER data, and as such, require a printf
+ conversion for a character array.
+</para>
+<para>
+examples:
+</para>
+<screen format="linespecific">
+ IFIELD IGNORE,"","%14.14s" # (writes a 14 character blank field)
+ IFIELD IGNORE,"","%s" # (writes a blank field on output)
+</screen>
+</section>
+
+<section id="style_def_constant">
+<title>CONSTANT</title>
+<para>
+ CONSTANT fields are, of course, constant. They are ignored on input,
+ however they write CONSTANT data on output. As such, they require a
+ DEFAULT VALUE and a printf conversion for a character array.
+</para>
+<para>
+examples:
+</para>
+<screen format="linespecific">
+ IFIELD CONSTANT,"FFFFFF","%s" # (writes "FFFFFF" in the field)
+ IFIELD CONSTANT,"01/01/70","%s" # (a constant date field)
+</screen>
+</section>
+
+<section id="style_def_index">
+<title>INDEX</title>
+<para>
+ An INDEX field is used ONLY on output. The INDEX constant defines a field
+ that, at output, contains the sequence number of the waypoint being
+ written, starting at 0. An index is managed internally as an INTEGER
+ and requires an INTEGER printf conversion. An INDEX has one special
+ property. The DEFAULT VALUE of the index is added to the index
+ on each iteration (to allow indexes starting at 1, 100, etc..).
+</para>
+<para>
+examples:
+</para>
+<screen format="linespecific">
+ IFIELD INDEX,"0","%04d" # (Starts counting at zero)
+ IFIELD INDEX,"","%04d" # (Starts counting at zero)
+ IFIELD INDEX,"1","%04d" # (Starts counting at one)
+</screen>
+</section>
+
+<section id="style_def_shortname">
+<title>SHORTNAME</title>
+<para>
+ A SHORTNAME is generally the waypoint name of the data being processed.
+ SHORTNAME maps directly to the GPSBabel variable ->shortname. A SHORTNAME
+ is CHARACTER data and requires a character array printf conversion.
+</para>
+<para>
+example:
+</para>
+<screen format="linespecific">
+ IFIELD SHORTNAME,"","%s" # (write shortname in the output file)
+</screen>
+</section>
+
+<section id="style_def_description">
+<title>DESCRIPTION</title>
+<para>
+ A DESCRIPTION is generally a long description of the waypoint. A
+ DESCRIPTION maps to the GPSBabel variable ->description and is otherwise
+ handled exactly like a SHORTNAME.
+</para>
+<para>
+examples:
+</para>
+<screen format="linespecific">
+ IFIELD DESCRIPTION,"","%s" # (write description in the output file)
+</screen>
+</section>
+
+<section id="style_def_notes">
+<title>NOTES</title>
+<para>
+ NOTES are generally everything else about a waypoints. NOTES map to the
+ GPSBabel variable ->notes and is otherwise handled exactly like a
+ SHORTNAME.
+</para>
+</section>
+
+<section id="style_def_url">
+<title>URL</title>
+<para>
+ URL is a URL for the waypoint. URL maps to the GPSBabel variable
+ ->url and is otherwise handled exactly like a SHORTNAME.
+</para>
+<para>
+example:
+</para>
+<screen format="linespecific">
+ IFIELD URL,"","%s" # (writes the URL in the output file)
+</screen>
+</section>
+
+<section id="style_def_urllinktext">
+<title>URL_LINK_TEXT</title>
+<para>
+ URL_LINK_TEXT is a textual description of where a URL points.
+ URL_LINK_TEXT maps to the GPSBabel variable ->url_link_text and
+ is otherwise handled exactly like a SHORTNAME.
+</para>
+<para>
+example:
+</para>
+<screen format="linespecific">
+ IFIELD URL_LINK_TEXT,"","%s" # (writes link text in the output file)
+</screen>
+</section>
+
+<section id="style_def_icondescr">
+<title>ICON_DESCR</title>
+<para>
+ ICON_DESCR is a textual description of an icon type for a waypoint.
+ ICON_DESCR maps to the GPSBabel variable ->icon_desc and is otherwise
+ handled exactly like a SHORTNAME.
+</para>
+<para>
+example:
+</para>
+<screen format="linespecific">
+ IFIELD ICON_DESCR,"","%s" # (writes link text in the output file)
+</screen>
+</section>
+
+<section id="style_def_latdec">
+<title>LAT_DECIMAL</title>
+<para>
+ LAT_DECIMAL defines LATITUDE in DECIMAL format. Note that this is a PURE
+ signed decimal format (i.e. -91.0000). This data is handled internally as
+ a DOUBLE PRECISION FLOAT and requires a FLOATING POINT printf conversion.
+</para>
+<para>
+example:
+</para>
+<screen format="linespecific">
+ IFIELD LAT_DECIMAL,"","%f"
+</screen>
+</section>
+
+
+<section id="style_def_londec">
+<title>LON_DECIMAL</title>
+<para>
+ See LAT_DECIMAL, except LON_DECIMAL defines LONGITUDE.
+</para>
+</section>
+
+<section id="style_def_latint32">
+<title>LAT_INT32DEG</title>
+<para>
+ LAT_INT32DEG defines LATITUDE in what I call INT32DEGREES. This value is
+ a signed LONG INTEGER and requires a LONG INTEGER printf conversion.
+ (This format is only used by some DeLorme products.)
+</para>
+<para>
+example:
+</para>
+<screen format="linespecific">
+ IFIELD LAT_INT32DEG,"","%ld"
+</screen>
+</section>
+
+<section id="style_def_lonint32">
+<title>LON_INT32DEG</title>
+<para>
+ See LON_INT32DEG except LON_INT32DEG defines LONGITUDE.
+</para>
+</section>
+
+<section id="style_def_latdirdec">
+<title>LAT_DECIMALDIR / LAT_DIRDECIMAL</title>
+<para>
+ LAT_DECIMALDIR and LAT_DIRDECIMAL define LATITUDE in DECIMAL format
+ with the added bonus of a 'N/S' or 'E/W' direction character. This data
+ is handled internally as a DOUBLE PRECISION FLOAT and a single
+ CHARACTER and requires a FLOATING POINT as well as a CHARACTER printf
+ conversion. The only difference between the two is whether the directional
+ character appears before (LAT_DIRDECIMAL) or after (LAT_DECIMALDIR) the
+ decimal number.
+</para>
+<para>
+examples:
+</para>
+<screen format="linespecific">
+ IFIELD LAT_DECIMALDIR,"","%f %c" # (writes 31.333 N)
+ IFIELD LAT_DIRDECIMAL,"","%c %f" # (writes N 31.333)
+</screen>
+</section>
+
+<section id="style_def_londirdec">
+<title>LON_DECIMALDIR / LON_DIRDECIMAL</title>
+<para>
+ Same as LAT_DECIMALDIR / LAT_DIRDECIMAL except LON_ defines LONGITUDE.
+</para>
+</section>
+
+<section id="style_def_latlondir">
+<title>LAT_DIR / LON_DIR</title>
+<para>
+ LAT_DIR returns the single character 'N' or 'S' depending on the
+ hemisphere of the latitude. LON_DIR returns 'E' or 'W' depending on
+ the hemisphere of the longitude.
+</para>
+</section>
+
+<section id="style_def_lathuman">
+<title>LAT_HUMAN_READABLE</title>
+<para>
+ LAT_HUMAN_READABLE defines LATITUDE in a human-readable format. This
+ format is probably the most expressive format. It is similar to
+ LAT_DECIMALDIR in that it requires multiple printf conversions, but it
+ is far more flexible as to the contents of those conversions. On read,
+ the printf conversions are ignored and GPSBabel attempts to determine the
+ latitude and longitude based on what is in the file.
+</para>
+<para>
+examples:
+</para>
+<screen format="linespecific">
+ IFIELD LAT_HUMAN_READABLE,"","%c %d %f" # (writes N 31 40.000)
+ IFIELD LAT_HUMAN_READABLE,"","%d deg %f min %c"
+ # (writes "31 deg 40.000 min N")
+ # Note that this string will confuse the reading routine due
+ # to the letter "n" in "min" and the letter "e" in "deg."
+ IFIELD LAT_HUMAN_READABLE,"","%d %d %f%c" # (writes 31 40 00.000N)
+</screen>
+</section>
+
+<section id="style_def_lonhuman">
+<title>LON_HUMAN_READABLE</title>
+<para>
+ See LAT_HUMAN_READABLE except LON_HUMAN_READABLE defines LONGITUDE.
+</para>
+</section>
+
+<section id="style_def_latlonhuman">
+<title>LATLON_HUMAN_READABLE</title>
+<para>
+ LATLON_HUMAN_READABLE is like LAT_HUMAN_READABLE and LON_HUMAN_READABLE
+ except that it reads and writes both latitude and longitude as a single
+ field. On write, the same format specifier is used for both coordinates.
+ On read, GPSBabel does exactly the same thing it does for
+ LAT_HUMAN_READABLE or LON_HUMAN_READABLE.
+</para>
+<para>
+example:
+</para>
+<screen format="linespecific">
+ IFIELD LATLON_HUMAN_READABLE,"","%c %d %f"
+ # (writes "N 31 40.126 W 85 09.62" as a single field)
+</screen>
+</section>
+
+<section id="style_def_latnmea">
+<title>LAT_NMEA</title>
+<para>
+ Defines the latitude in the format used by the NMEA standard which is
+ degrees multiplied by 100 plus decimal minutes.
+</para>
+<para>
+example:
+</para>
+<screen format="linespecific">
+ IFIELD LAT_NMEA, "%f", "%08.3f" # (writes 3558.322)
+</screen>
+</section>
+
+<section id="style_def_lonnmea">
+<title>LON_NMEA</title>
+<para>
+ Defines the longitude in the format used by the NMEA standard which is
+ degrees multiplied by 100 plus decimal minutes.
+</para>
+<para>
+example:
+</para>
+<screen format="linespecific">
+ IFIELD LON_NMEA, "%f", "%010.3f" # (writes -08708.082)
+</screen>
+</section>
+
+<section id="style_def_altfeet">
+<title>ALT_FEET</title>
+<para>
+ ALT_FEET is the position's ALTITUDE in FEET. This value is treated as
+ a SIGNED DOUBLE PRECISION FLOAT and requires a FLOATING POINT printf
+ conversion.
+</para>
+<para>
+example:
+</para>
+<screen format="linespecific">
+ IFIELD ALT_FEET,"","%.0f"
+</screen>
+</section>
+
+<section id="style_def_altmeters">
+<title>ALT_METERS</title>
+<para>
+ ALT_METERS is identical to ALT_FEET with the exception that the altitude
+ is in METERS.
+</para>
+</section>
+
+<section id="style_def_heartrate">
+<title>HEART_RATE</title>
+<para>
+ Heart rate, measured in beats per minute. Only valid for units with
+ heart rate monitor features (i.e. Garmin Forerunner 301).
+</para>
+<para>
+example:
+</para>
+<screen format="linespecific">
+ IFIELD HEART_RATE,"","%d"
+</screen>
+</section>
+
+<section id="style_def_exceltime">
+<title>EXCEL_TIME</title>
+<para>
+ EXCEL_TIME is the waypoint's creation time, if any. This is actually
+ the decimal days since 1/1/1900 and is handled internally as a DOUBLE
+ PRECISION FLOAT and requires a FLOATING POINT printf conversion.
+</para>
+<para>
+example:
+</para>
+<screen format="linespecific">
+ IFIELD EXCEL_TIME,"","%11.5f"
+</screen>
+</section>
+
+<section id="style_def_timettime">
+<title>TIMET_TIME</title>
+<para>
+ TIMET_TIME is the waypoint's creation time, if any. This is actually
+ the integer seconds since 1/1/1970 (let's not start the holy war) and
+ is handled internally as a LONG INTEGER and requires a LONG INTEGER
+ printf conversion.
+</para>
+<para>
+example:
+</para>
+<screen format="linespecific">
+ IFIELD TIMET_TIME,"","%ld"
+</screen>
+</section>
+
+<section id="style_def_yyyymmdd">
+<title>YYYYMMDD_TIME</title>
+<para>
+ YYYYMMDD_TIME is the waypoint's creation time, if any. It's a single
+ decimal field containing four digits of year, two digits of month,
+ and two digits of date. Internally it is a LONG INTEGER and thus
+ requires a LONG INTEGER printf conversion.
+</para>
+<para>
+example:
+</para>
+<screen format="linespecific">
+ IFIELD YYYYMMDD_TIME,"","%ld"
+</screen>
+</section>
+
+<section id="style_def_gmttime">
+<title>GMT_TIME</title>
+<para>
+ GMT_TIME is the waypoint's creation time, in UTC time zone. It uses the
+ strptime conversion format tags.
+</para>
+<para>
+example:
+</para>
+<screen format="linespecific">
+ IFIELD GMT_TIME,"","%m/%d/%Y %I:%M:%D %p"
+</screen>
+<para>
+ Search the web for 'strptime man page' for details strptime, but one
+ such page can be found at
+<ulink url="http://www.die.net/doc/linux/man/man3/strptime.3.html">http://www.die.net/doc/linux/man/man3/strptime.3.html</ulink>
+</para>
+</section>
+
+<section id="style_def_localtime">
+<title>LOCAL_TIME</title>
+<para>
+ LOCAL_TIME is the waypoint's creation time, in the local
+ time zone. It uses strptime conversion format tags. See GMT_TIME for a
+ reference.
+</para>
+<para>
+example:
+</para>
+<screen format="linespecific">
+ IFIELD LOCAL_TIME,"","%y-%m-%d"
+</screen>
+</section>
+
+<section id="style_def_hmsgtime">
+<title>HMSG_TIME</title>
+<para>
+ HMSG_TIME parses up to three time parts and am/pm string to add
+ this value to the previously parsed *_TIME field that contains
+ only a date. On output, will print the time in UTC.
+</para>
+<para>
+example:
+</para>
+<screen format="linespecific">
+ IFIELD HMSG_TIME,"","%d:%d:%d %s"
+</screen>
+</section>
+
+<section id="style_def_hmsltime">
+<title>HMSL_TIME</title>
+<para>
+ HMSG_TIME parses up to three time parts and am/pm string to add
+ this value to the previously parsed *_TIME field that contains
+ only a date. On output, will print the time in local time.
+</para>
+<para>
+example:
+</para>
+<screen format="linespecific">
+ IFIELD HMSL_TIME,"","%dh%dm"
+</screen>
+</section>
+
+<section id="style_def_isotime">
+<title>ISO_TIME</title>
+<para>
+ ISO_TIME is the waypoint's creation time, in ISO 8601 format,
+ which include time zone information.
+ It is expected to be in the format yyyy-mm-ddThh:mm:sszzzzz
+ where zzzzzz is the local time offset or the character Z
+ for UTC time.
+ On output, UTC 'Z' time zone will always be used.
+</para>
+<para>
+example:
+</para>
+<screen format="linespecific">
+ IFIELD ISO_TIME,"","%s"
+</screen>
+</section>
+
+<section id="style_def_geodiff">
+<title>GEOCACHE_DIFF</title>
+<para>
+ GEOCACHE_DIFF is valid only for geocaches and represents a DOUBLE
+ PRECISION FLOAT. This is the geocache "difficulty" rating as defined by
+ Groundspeak. A "three and a half star" cache would therefore be "3.5"
+</para>
+<para>
+example:
+</para>
+<screen format="linespecific">
+ IFIELD GEOCACHE_DIFF,"","%3.1f"
+</screen>
+</section>
+
+<section id="style_def_geoterr">
+<title>GEOCACHE_TERR</title>
+<para>
+ GEOCACHE_TERR is valid only for geocaches and represents a DOUBLE
+ PRECISION FLOAT. This is the geocache "terrain" rating as defined
+ by Groundspeak. A "three and a half star" cache would therefore be "3.5"
+</para>
+<para>
+example:
+</para>
+<screen format="linespecific">
+ IFIELD GEOCACHE_TERR,"","%3.1f"
+</screen>
+</section>
+
+<section id="style_def_geocontainer">
+<title>GEOCACHE_CONTAINER</title>
+<para>
+ GEOCACHE_CONTAINER is valid only for geocaches and is heavily influenced
+ by the Groundspeak container types. Examples would include "Micro"
+ and "Virtual".
+</para>
+<para>
+example:
+</para>
+<screen format="linespecific">
+ GEOCACHE_CONTAINER,"","%s"
+</screen>
+</section>
+
+<section id="style_def_geotype">
+<title>GEOCACHE_TYPE</title>
+<para>
+ GEOCACHE_TYPE is valid only for geocaches and is heavily influenced
+ by the Groundspeak cache types. Examples would include "Event cache"
+ and "Multi-Cache".
+</para>
+<para>
+example:
+</para>
+<screen format="linespecific">
+ GEOCACHE_TYPE,"","%s"
+</screen>
+</section>
+
+<section id="style_def_geoplacer">
+<title>GEOCACHE_PLACER</title>
+<para>
+ GEOCACHE_PLACER is a string containing the name of the placer of a
+ geocache.
+</para>
+<para>
+example:
+</para>
+<screen format="linespecific">
+ GEOCACHE_PLACER,"","%s"
+</screen>
+</section>
+
+<section id="style_def_geofound">
+<title>GEOCACHE_LAST_FOUND</title>
+<para>
+ A long integer in format YYYYMMDD containing the last time this geocache
+ was found.
+</para>
+<para>
+example:
+</para>
+<screen format="linespecific">
+ GEOCACHE_LAST_FOUND,"","%ld"
+</screen>
+</section>
+
+<section id="style_def_geohint">
+<title>GEOCACHE_HINT</title>
+<para>
+ The hint for this geocache. No additional transformation (such as rot13)
+ will be performed on this string.
+</para>
+<para>
+example:
+</para>
+<screen format="linespecific">
+ GEOCACHE_HINT,"","%s"
+</screen>
+</section>
+
+<section id="style_def_pathdistmi">
+<title>PATH_DISTANCE_MILES</title>
+<para>
+ PATH_DISTANCE_MILES outputs the total length of the route or track from
+ the start point to the current point, in miles. This and the altitude
+ could be used to create an elevation profile. PATH_DISTANCE_MILES is
+ a DOUBLE PRECISION FLOAT.
+</para>
+<para>
+ PATH_DISTANCE_MILES is not valid as an input field.
+</para>
+<para>
+ PATH_DISTANCE_MILES is only meaningful if the data comes from a track
+ or a route; waypoint data will generate essentially meaningless output.
+</para>
+<para>
+example:
+</para>
+<screen format="linespecific">
+ PATH_DISTANCE_MILES,"","%f"
+</screen>
+</section>
+
+<section id="style_def_pathdistkm">
+<title>PATH_DISTANCE_KM</title>
+<para>
+ PATH_DISTANCE_KM is like PATH_DISTANCE_MILES except it outputs the
+ length in kilometers.
+</para>
+</section>
+
+<section id="style_def_pathspeed">
+<title>PATH_SPEED</title>
+<para>
+ Speed in meters per second. Gpsbabel does NOT calculate this data by
+ default; it is read from the input file if present. (If not present,
+ it may be calculated with the <link linkend="filter_track">track</link>
+ filter.)
+</para>
+<para>
+example:
+</para>
+<screen format="linespecific">
+ PATH_SPEED,"","%f"
+</screen>
+</section>
+
+<section id="style_def_pathcourse">
+<title>PATH_COURSE</title>
+<para>
+ Course in degerees. Gpsbabel does not calculate this data by default;
+ it is read from the input file if present. (If not present, it may be
+ calculated with the <link linkend="filter_track">track</link> filter.)
+</para>
+<para>
+example:
+</para>
+<screen format="linespecific">
+ PATH_COURSE,"","%f"
+</screen>
+</section>
+
+<section id="style_def_dop">
+<title>GPS_HDOP / GPS_VDOP / GPS_PDOP</title>
+<para>
+ GPS horizontal / vertical / positional dilution of precision
+ parameters. Needs float conversion.
+</para>
+<para>
+example:
+</para>
+<screen format="linespecific">
+ GPS_HDOP,"","%f"
+</screen>
+</section>
+
+<section id="style_def_gpssat">
+<title>GPS_SAT</title>
+<para>
+ Number of satellites used for determination of the position. Needs
+ integer conversion.
+</para>
+<para>
+example:
+</para>
+<screen format="linespecific">
+ GPS_SAT,"","%d"
+</screen>
+</section>
+
+<section id="style_def_gpsfix">
+<title>GPS_FIX</title>
+<para>
+ Type of fix (see GPX spec or <link linkend="filter_track">track</link>
+filter). Needs string conversion.
+</para>
+<para>
+example:
+</para>
+<screen format="linespecific">
+ GPS_FIX,"","%s"
+</screen>
+</section>
+</section> <!-- definitions -->
+
+<section id="style_examples">
+<title>Examples</title>
+<para>
+For examples on using the XCSV module, please see the
+<filename>*.style</filename> files in the
+<filename>style/</filename> subdirectory of GPSBabel.
+</para>
+</section> <!-- examples -->
+
+<section id="style_notes">
+<title>Miscellaneous Notes</title>
+<section id="style_notes_default">
+<title>Default Values</title>
+<para>
+Default values are supported for any output fields that contain pure
+ character data output such as URL and NOTES. Default values are only
+ written on output and are not used to supplement missing input. When
+ using default values your mileage will vary greatly depending on the
+ input formats used to populate waypoint data.
+</para>
+</section>
+</section><!-- notes -->
+
+</appendix><!-- style -->
projects / gpsbabel.git / commitdiff